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1  Abstract 


The  Air  Force  has  three  mission  elements,  air,  space  and  cyber  that  it  must  command  and  control 
as  a  Joint  and  Coalition  partner.  Today’s  Air  Operations  Centers  (AOCs)  want  to  improve  multi- 
domain  collaboration.  To  address  these  challenges.  Air  Force  Research  Laboratory  Information 
Directorate  (AFRL/RI)  is  sponsoring  exploration  and  development  of  an  Integrated  Battle 
Planning  Capability  (IBPC)  to  coordinate  and  synchronize  planning  across  the  three  domains. 
As  a  first  step  toward  this  goal,  BAE  Systems  is  developing  Cornerstone,  a  suite  of  web  services 
for  mission  request  brokering,  dynamic  model  management,  plan  management,  and  a  Unified 
Plan  Representation  (UPR).  The  UPR  is  based  on  already  established  community  standards  and 
a  common  ontology  of  shared  and  domain-specific  concepts.  This  paper  describes  Cornerstone’s 
research  and  development  accomplishments  to  date,  including  an  overview  of  the  ontology, 
system  design,  and  elaboration  of  the  web  services.  Results  from  an  initial  Limited  Technology 
Experiment  (LTE)  are  reviewed.  In  the  LTE,  Cornerstone  services  correctly  used  the  Jena 
semantic  reasoning  engine  to  broker  air,  cyber,  and  space  mission  option  data  among  simulated 
and  human  domain-planners. 

2  Introduction 

To  improve  unity  of  effort,  the  US  Air  Force  has  called  for  improving  coordination  and 
synchronization  among  its  mission  domains,  air,  space  and  cyber,  to  keep  up  with  an 
increasingly  dynamic  adversary  decision  cycle,  and  to  be  more  efficient  at  synergizing  available 
resources.  Current  computerized  planning  systems  lack  both  a  common  basis  for  representing 
and  maintaining  cross-domain  mission  needs  and  a  coherent  structure  to  guide  workflow  and 
communication. 

To  address  these  challenges,  AFRL  is  sponsoring  development  of  Cornerstone,  a  foundational 
data  representation  and  suite  of  services  for  brokering  and  managing  missions  that  span  air, 
cyber,  and  space  operations;  across  both  mission  domains  and  security  domains.  During  the  first 
phase  of  Cornerstone  (Mar-Nov  2010),  AFRL,  BAE  Systems,  and  supporting  contractor 
Metatech  Corp,  conducted  knowledge  acquisition  workshops,  collected  many  existing  schemas 
and  Community  of  Interest  (COI)  documents,  and  synthesized  salient  schemas  and  standards  into 
a  shared  ontology  supporting  the  three  targeted  domains.  During  Phase  2  (Aug  2010-  Sep  2011), 
the  team  focused  on  prototyping  components  and  web  services  for  request  brokering,  plan 
management,  and  model  management. 

To  get  things  working  together,  we  also  designed  and  built  additional  infrastructural  services  for 
interfacing  with  existing,  external  planners  and  translating  between  them.  At  the  end  of  Phase  2, 
the  end-to-end  workflow,  run-time  performance  and  extensibility  of  the  prototype  system  were 
tested  in  various  configurations  during  a  Limited  Technology  Experiment  (LTE)  held  on-site  at 
AFRL  Rome  Research  Site.  This  experiment  demonstrated  Cornerstone’s  ability  to  broker 
requests,  and  store  and  retrieve  mission  data  across  all  three  domains.  It  demonstrated  how 
Cornerstone  services  could  extend  models  rapidly  on-the-fly  at  run-time  to  process  evolving 
mission  needs  and  planner  capabilities.  The  experiment  also  exposed  specific  areas  for 
performance  improvement  that  were  addressed  early  in  the  subsequent  phase. 
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This  paper  describes  Cornerstone  research  activities  and  findings,  beginning  with  Section  3 
describing  our  multi-domain  ontology  and  model  representation  approach  and  design.  Section  4 
provides  an  overview  of  our  system  design.  Section  5  discusses  the  five  Cornerstone  web 
services,  and  Section  6  covers  integration  of  the  end-to-end  system.  In  Section  7  we  provide  a 
more  detailed  account  of  the  procedures  and  results  observed  in  the  Phase  2  LTE.  We  close  with 
a  summary  of  future  planned  research. 


3  Cross-Domain  Knowledge  Representation 

One  of  the  primary  reasons  behind  the  interoperability  struggles  we  have  been  facing  with 
current  C2  systems  is  their  use  of  what  used  to  be  state-of-the-art:  monolithic  relational  databases 
and  stove-piped  applications  necessarily  specialized  for  each  function.  Because  early 
applications  were  designed  and  built  in  the  ancient  days  of  manual,  paper-based  techniques,  it 
was  deemed  acceptable,  and  even  necessary,  that  communication  between  functions  used 
human-readable  text  messaging.  These  systems  have  since  proven  very  expensive  to  extend  and 
modify  to  get  them  interoperating  with  each  other.  A  consequence  of  this  state  of  affairs  and  the 
“new”  need  for  interoperability  is  the  proliferation  of  custom  translators,  adaptors  and  interface 
wrappers. 


The  evolution  away  from  monolithic  databases  to  more  semantically  aware  and  agile  methods 
using  standards  such  as  extensible  Markup  Language  (XML),  Resource  Description  Framework 
(RDF),  and  Web  Ontology  Language  (OWL)  hold  high  potential  to  increase  extensibility  and 
reduce  long-term  integration  and  maintenance  costs  [OWL].  For  this  reason,  we  are 
experimenting  with  OWL  as  the  representation  language  for  Cornerstone’s  multi-domain 
ontology. 


Figure  1:  Cornerstone  uses  the  OWL  semantic  web  standard  and  object-oriented  design  principles  to  model 
shared  vs.  domain-specific  concepts  for  plans  and  models. 

As  shown  in  Figure  1,  our  ontology  is  designed  with  three  layers  (left)  and  four  OWL  file 
segments:  Core,  Air,  Cyber,  and  Space  (right).  The  core  layer  is  an  upper  ontology  containing 
the  most  general  concepts  such  as  AbstractObject,  Entity,  EntityState,  SpatialThing,  and 
Situation.  The  middle  layer  encodes  concepts  specific  to  C2  models  (e.g.,  resources, 
organizations,  planners)  and  plans  (e.g.,  requests,  tasks,  missions,  intent)  but  still  generalizable 
across  specific  domains.  The  third  layer  includes  domain-specific  model  and  plan  concepts 
unique  to  a  specific  mission  domain.  In  this  way,  a  mission  domain  does  not  have  to  change  to 
comply  with  an  evolving  standard,  thereby  giving  us  an  affordable  way  of  interoperating. 

The  main  concepts  in  the  Cornerstone  Core  Ontology  are  depicted  in  Figure  2  below.  A  Mission 
is  a  high  level  task  related  to  accomplishing  a  military  objective.  A  Task  Request  (recently 
simplified  to  Request),  represents  a  request  by  one  planning  agent  for  another  agent  to 
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accomplish  a  certain  task.  Requests  in  the  Cornerstone  ontology  specify  “what”  a  task  should 
accomplish  but  not  “how.”  A  Request  must  include  the  desired  effect,  time  window,  and  a 
location  or  target,  but  typically  does  not  specify  a  particular  domain;  often  an  effect  may  be 
fulfilled  by  any  multiple  of  domain  planners.  A  Mission  Task  (simplified  to  Task)  is  a  military 
action  that  can  be  assigned  to  a  military  organization  with  resources  in  order  to  achieve  an 
objective.  A  Task  can  be  performed  using  one  or  more  Resources  (e.g.,  a  fighter  aircraft  or  a 
cyber  capability),  each  under  the  control  of  an  Organization.  An  Organization  may  also  issue 
requests  for  original  or  supporting  missions  and  tasks.  The  self-referential  link  on  Task  allows 
for  an  arbitrarily  deep  nests  of  such  supporting  tasks.  The  self-referential  link  on  Organization 
can  be  used  to  represent  a  hierarchy  of  subordinate  military  units. 


Figure  2:  The  Core  Ontology  captures  concepts  common  to  all  planning  domains,  including  Mission,  Reqnest, 

Task,  Organization,  and  Resource. 

The  domain-specific  ontology  layer  extends  the  core  concepts  to  encode  concepts  and 
relationships  specific  to  air,  cyber,  or  space.  Figure  3  shows  a  selected  subset  of  concepts  from 
all  three  domains  and  all  four  ontology  segments.  It  also  depicts,  via  colored,  lettered  boxes,  the 
original  sources  that  informed  the  design  of  the  concepts  in  that  box.  Much  of  the  Core  ontology 
was  derived  from  the  Universal  Core  (UCore),  an  XML-based  schema  for  U.S  government 
interoperability.  It  describes  general  concepts  for  Who,  What,  When,  and  Where  [UCore].  The 
air-domain  ontology  is  mainly  based  on  recent  data  standards  published  by  the  Air  Operations 
Community  of  Interest  (AO  COI).  The  AO  COI  defines  the  Mission  Task  Request  (MTR)  for 
basic  mission  requests,  and  the  Common  Mission  Definition  (CMD)  for  representing  more 
specific  air  mission  requests,  tasks  and  related  concepts  such  as  RoutePoint  (a  Route  Point  is  a 
description  of  a  location  at  which  a  sub-task  of  a  Mission  occurs). 
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Figure  3:  Cornerstone’s  ontology  synthesizes  concepts  and  relationships  from  emerging  and  established  air, 
cyber,  and  space  data  standards  from  prominent/authoritative  communities  of  interest. 

Cornerstone  adapted  additional  air  concepts  such  as  Capability,  Objective,  Aircraft,  and 
FixedObjects  vs.  MobileObjects,  and  others  from  BAE’s  previous  research  in  automated  plan 
generation  under  the  Defense  Advanced  Research  Projects  Agency  (DARPA)  Joint  Air  Ground 
Unified  Adaptive  Re-planner  (JAGUAR)  program  [JAGUAR],  For  the  cyber  domain. 
Cornerstone  imported  and  expanded  on  concepts  from  AFRL’s  recent  Treadstone  Computer 
Network  Attack  characterization  research,  also  performed  by  BAE  [Treadstone],  Cyber-specific 
concepts  include  ComputerNetwork,  ComputerNetworkNode,  and  Friendly  vs.  NeutralParty 
affiliation.  Space-domain  ontology  concepts  and  missions  such  as  Satellite,  Space  ISR,  and 
Overhead  Persistent  Infrared  ISR  (OPIR),  were  defined  by  partners  in  Metatech  Corp.  They 
based  designs  on  their  extensive  experience  developing  space  warfare  scenarios  and  datasets  for 
space  operations  wargames  and  recent  space  situational  awareness  research  for  AF  Space 
Command. 


4  System  Design 

In  parallel  with  the  multi-domain  ontology  development  described  above,  the  Cornerstone  team 
designed  and  prototyped  the  software  design  shown  in  Figure  4.  The  architecture  is  service 
oriented  and  includes  Java  2  Enterprise  web  service  standards,  utilizing  the  Service  Oriented 
Architecture  (SOA)  stack  embodied  in  the  Navy’s  Afloat  Core  Services  (ACS),  which  has 
standardized  on  RedHat  CentOS  6.2  (Linux  2.6)  and  JBOSS  5.1  [ACS],  The  thin  blue  and 
yellow  cylinders  represent  http-based  communication  capabilities  among  services  and  various 
external  planning  tools  (of  which  our  current  focus  is  on  air,  cyber,  space,  and  joint  strategy 
planning).  These  external  planners  may  be  either  manual  or  automated  as  long  as  they  conform 
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to  the  Cornerstone  UPR  and  request  workflow  encoded  in  its  exposed  Web  Service  Definition 
Language  (WSDL)  specification. 


_ 

x  V . .  . 
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Figure  4:  Cornerstone  consists  of  web  services  for  plan,  model,  and  request  management,  and  planner 
interface  and  data  translation  services  to  provide  interoperability  with  domain-specific  planners. 

On  initialization.  Cornerstone’s  Model  Management  Service  ingests  the  four  OWL  files 
encoding  its  Core,  Air,  Cyber,  and  Space  ontology  concept  definitions,  as  well  as  RDF  planner 
capability  models  describing  active  organizations,  planners,  and  the  types  of  effects  their 
capabilities  can  achieve.  Cornerstone’s  Plan  Management  Service  also  initializes  the  Plan 
Repository,  a  PostgreSQL  knowledge  base  storing  all  past,  current,  and  potential  future  missions, 
tasks,  requests,  supporting  objects  and  their  interrelationships  in  RDF  triple  format.  The  operator 
to  the  left  of  Cornerstone  represents  a  notional  Situation  display  in  a  Program  Of  Record  (POR) 
that  would  offer  on-demand  queries  and  visualization  of  multi-domain  missions  stored  in  the 
Plan  Repository. 

We  now  describe  briefly  the  five  web  services  comprising  the  Cornerstone  system: 

•  Request  Management  Service  (RMS)  -  Enables  collaboration  among  air,  space  and  cyber 
domains  by  performing  brokering  business  logic  for  mission  requests  from  one  domain  planner 
to  others,  and  processing  options.  RMS  also  tracks  and  maintains  the  request  workflow. 

•  Plan  Management  Service  (PM)  -  Provides  access  to  plans,  requests,  tasks,  and  other 
mission  objects  stored  in  the  Plan  Repository.  It  includes  the  full  suite  of  semantic  Create,  Read, 
Update,  Delete,  and  Find  (CRUDF)  operations  for  ManagedObjects. 

•  Model  Management  Service  (MMS)  -  Initializes  the  Cornerstone  ontology  and  manages 
dynamic  updates  to  models,  including  new  effects,  planner  capabilities,  and  world  state. 

•  Planner  Interface  Service  (PI)  -  Provides  a  common  external  interface  to  Cornerstone 
services.  Also  mediates  between  Cornerstone  derived  processing  and  external  planners’ 
planning  process(es). 

•  Data  Translation  Service  (DTS)  -  Translates  documents  from  external  planners’ 
representations  into  Cornerstone’s  OWL  representation  (and  back). 

The  next  section  describes  these  web  services  in  more  detail. 
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5  Cornerstone  Services 


The  Cornerstone  team  employed  a  spiral  implementation  in  which  the  first  spiral  focused  on 
developing  and  unit  testing  the  five  services  as  stand-alone  Java  components,  the  second  spiral 
focused  on  integration  and  system  testing  of  the  end-to-end  workflow  across  components,  and 
the  third  spiral  focused  on  exposing  each  component’s  functionality  as  a  web  service,  utilizing 
the  Apache  CXF  framework  [CXF],  This  last  stage  began  with  the  Planner  Interface  Service, 
since  it  is  the  main  external  point  of  contact  for  domain  planners,  and  proceeded  with  Request 
Management,  Plan  Management,  Data  Translation,  and  Model  Management  Services. 

5.1  Request  Management  Service 

RMS  enables  collaboration  among  air,  space  and  cyber  domains  by  accepting,  coordinating  and 
processing  requests  for  mission  tasks.  RMS  matches  requests  to  appropriate  planners  based  on 
the  Model  Management  Service’s  models  of  domain  capabilities  and  sends  the  request  to 
appropriate  planners  (e.g.,  their  planning  domain,  organization,  area  of  responsibility,  and  the  set 
of  effect  types  they  support).  It  continues  to  track  the  request  workflow  until  the  request  is 
denied  or  accepted. 

As  shown  in  Figure  5  below  (left  bottom),  RMS  acts  as  a  task  broker  among  all  participating 
planners  of  varying  domain  specialties  and  echelons.  Typically,  one  external  planner  is  the 
requestor,  and  one  or  more  external  planners  serve  as  responders,  each  providing  one  or  more 
mission  options  that  could  fulfill  the  request.  Current  experiments  have  RMS  convey  the  list  of 
candidate  planners  to  the  request  originator,  who  selects  none,  any,  or  all  of  the  suggested 
planners.  Based  on  the  selection,  RMS  routes  the  request  to  the  chosen  planners.  Each  planner 
processes  the  request  and  sends  an  asynchronous  response  message  to  RMS  with  one  or  more 
mission  options.  RMS  again  routes  these  options  to  the  request  originator  who  selects  one  or 
more  of  the  candidate  options.  Finally,  RMS  sends  an  approval/acceptance  notification  to  the 
external  planners  whose  options  were  selected.  It  is  then  assumed  (for  now)  that  the  FOR 
planners  will  include  the  mission  in  their  next  Tasking  Order. 


Support  Requests 


Figure  5:  The  Request  Management  Service  brokers  both  original  task  requests  for  the  main  plan  and 
support  requests  (e.g.  air  refueling,  space  ISR)  among  external  domain  planners 
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RMS  also  performs  a  check  for  each  incoming  request  to  determine  if  there  is  an  existing 
mission  in  the  Plan  Repository  that  can  fulfill  the  needs  of  the  request.  If  a  match  is  found,  it  is 
presented  by  RMS  to  the  user  as  a  mission  option  and  the  user  may  request  reuse  of  the  existing 
option  or  ask  for  new  options  from  matching  domain  planners. 

RMS  also  supports  multiple  stages  of  mission  requests  as  support  requests,  (Figure  5,  right). 
Examples  of  support  requests  include  within-mission  support  such  as  mid-air  refueling  or  follow¬ 
up  requests  for  space  ISR  to  perform  Battle  Damage  Assessment  (BDA)  to  confirm  successful 
effects.  In  a  support  request,  an  external  planner  determines  that  it  cannot  fulfill  the  original 
request  on  its  own,  possibly  due  to  limitations  in  resource  availability,  so  it  issues  a  secondary 
request  to  RMS  describing  the  supporting  task  requirements  (time  window,  effect  type,  etc.). 
RMS  manages  these  requests  using  the  same  workflow  as  above,  but  after  processing  is 
complete,  the  resulting  task  support  relationships  and  selected  planners  and  mission  options  are 
stored  hierarchically  in  the  Plan  Repository  via  the  Plan  Management  Service. 

In  an  operational  environment,  RMS  offers  a  scalable,  flexible  approach  to  collaborative 
planning  by  decoupling  direct  dependencies  among  external  planners.  By  leveraging  extensible 
models  of  domain-specific  planner  capabilities,  it  continuously  provides  human  and  automated 
planners  with  a  wide  range  of  options  for  fulfilling  incoming  mission  requests,  all  resulting  in 
more  efficient,  robust  plans. 

5.2  Plan  Management  Service 

The  Plan  Management  (PM)  Service  is  responsible  for  storing  and  updating  the  evolving  multi- 
domain  plan  as  planner  clients  issue  new  requests  and  users  approve  resulting  options  via  RMS 
process. 

The  PM  Service  exposes  the  full  array  of  relational  database  operations:  Create,  Read,  Update, 
Delete,  and  Find  (CRUDF).  However,  the  Plan  Repository’s  underlying  RDF  triple 
representation  is  more  flexible  than  traditional  relational  tables  in  that  it  allows  a  wider  range  of 
changes  to  the  schema  on-the-fly  at  run-time  without  affecting  existing  data.  Cornerstone  uses 
SQL  Database  (SDB),  a  component  of  Apache  Jena,  to  support  RDF  query  and  storage  [JENA]. 
SDB  supports  a  range  of  underlying  SQL  database  instances  for  storage;  we  have  demonstrated 
compatibility  with  both  PostgreSQL  and  MySQL.  The  use  of  RDF  also  enables  the  PM  Service 
to  expose  a  SPARQL  query  interface,  which  offers  more  expressive  semantic  queries  than  SQL 
alone. 

Another  important  design  feature  of  the  PM  Service  is  support  for  multiple  stored 
representations.  Because  Cornerstone’s  ontology  is  not  intended  to  be  exhaustive  for  all 
domains,  we  are  experimenting  with  an  option  to  store  a  payload  containing  the  original  native 
representation  of  a  message  or  object  alongside  the  Cornerstone  OWL  representation  (a  digest). 
The  PM  Service  maintains  this  digest-payload  association  in  the  repository  and  makes  it 
available  to  any  clients  who  may  require  the  additional  detail  for  replanning,  plan  assessment,  or 
visualization. 

In  addition  to  SPARQL  or  SQL  queries,  the  PM  Service  provides  an  object-level  notification 
mechanism  in  which  clients  may  subscribe  to  events  relating  to  the  lifecycle  of  Cornerstone 
ManagedObjects.  ManagedObjects  represent  a  kind  of  “first  class’’  object,  particularly  those 
types  referenced  directly  in  the  top-level  API,  such  as  Mission,  Task,  Request,  Organization, 
Resource,  etc. 
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5.3  Model  Management  Service 

The  MMS  performs  a  similar  function  to  the  PM  Service  but  as  the  name  suggests,  it  mediates 
access  to  Cornerstone  models  rather  than  plan  data.  There  are  three  main  types  of  models,  each 
with  increasing  dynamicity: 

•  Domain  Ontologies  -  The  air,  cyber,  and  space  segments  of  the  ontology  may  require 
periodic  extensions,  for  example,  to  incorporate  concepts  for  new  cyber  capabilities  or  mission 
types,  given  the  rapidly  evolving  nature  of  cyber  supporting  warfare.  These  changes  may  occur 
at  run-time  or  load-time,  and  are  expected  to  occur  relatively  infrequently. 


Figure  6:  The  Model  Management  Service  maintains  the  OWL  ontology  and  dynamic  capability  models,  and 
the  rnles  for  complex  reasoning  to  match  domain  planners  against  reqnests. 

•  Planner  Capabilities  -  The  MMS  contains  capability  models  of  each  domain  planner  and 
the  effect  types  and  mission  types  that  it  supports  so  that  RMS  can  effectively  broker  requests  to 
the  best-suited  domain  planners.  These  capability  models  may  be  readily  extended  as  improved 
versions  of  existing  domain  planners  or  newly  deployed  planners  come  on-line.  To  facilitate 
rapid  extensions  to  the  broker’s  reasoning,  we  use  a  Jena  OWL  encoding  scheme  of  the  business 
rules  for  selecting  eligible  planners,  as  illustrated  by  the  example  in  Figure  6.  In  this  example,  a 
request  for  cyber  support  for  an  attack  on  SamSiteOOl  is  matched  to  Cyberplanner  1  by  RMS 
because:  a)  it  has  the  ability  to  deploy  resources  against  nodes  of  type  ComputerNetwork;  b) 
SamSiteOOl  depends  on  the  computer  network  in  question;  and  c)  SamSiteOOl  is  in  the  area  of 
responsibility  for  CyberPlannerl. 

•  World  State  -  The  MMS  loads  an  initial  description  of  the  state  of  the  world  in  terms  of 
regions,  targets,  networks,  and  their  dependencies.  With  significantly  more  development,  these 
models  would  be  connected  to  live  operational  feeds  to  ensure  an  up-to-date  picture  is 
maintained  for  RMS  reasoning  and  command  staff  decision-making. 

Later,  in  Section  6,  we  discuss  an  experiment  thread  in  which  an  MMS  planner-capability  model 
was  dynamically  extended  to  support  a  new  type  of  effect  (i.e.,  during  run-time). 
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5.4  Planner  Interface  and  Data  Translation  Services 

For  external  planners  that  are  “Cornerstone-aware”  (i.e.,  those  that  already  produce  and/or  ingest 
data  that  is  compliant  with  Cornerstone’s  OWL  format),  the  above  services  are  sufficient  to 
enable  interoperability  with  Cornerstone’s  end-to-end  workflow.  Since  no  such  planners  exist 
yet  at  this  early  stage  of  development,  we  developed  two  additional  services  to  bootstrap  the 
integration  of  several  candidate  planners: 

•  The  Planner  Interface  (PI)  Service  acts  as  a  central  interface  point  for  non-Comerstone- 
aware  planners,  exposing  a  facade  interface  to  both  RMS  workflow  and  PM  Service  data  access 
functionality.  The  PI  Service  determines  which  translations  are  necessary  based  on  the  client 
data. 


•  The  Data  Translation  Service  (DTS)  exposes  bi-directional  mediation  functionality  for 
translation  of  request  and  mission-related  ManagedObjects.  Early  Cornerstone  efforts  currently 
support  translation  from  MTR  and  Space  Support  Request  (SSR)  XML  formats  to  its  internal 
format,  and  two-way  translation  of  CMD,  Air  Tasking  Order  (ATO),  Joint  Space  Tasking  Orders 
(JSTO),  and  the  BAE  Systems  cyber-planner  XML  format  (see  next  section).  Figure  7  illustrates 
the  DTS  translation  workflow.  An  external  planner  issues  a  request  or  mission  option  in  a  native 
format,  typically  XML-based,  which  is  translated  within  the  DTS  to  create  a  new 
ManagedObject  in  OWL.  The  native  XML  is  retained  as  the  payload  alongside  the  OWL  object 
in  the  Plan  Repository,  as  described  in  Section  5.2  above.  When  clients  request  this  object  in  the 
future,  the  DTS  translates  the  current  OWL  instance  to  the  native  format  but  also  attaches  the 
original  native  payload,  which  typically  offers  a  level  of  detail  beyond  what  is  stored  in  the 
ManagedObject. 


External 

XML  Doc 

A 

Planner 

Figure  7:  The  Data  Translation  Service  mediates  between  external  native  request  and  mission  formats  and 

Cornerstone’s  OWL-based  representation. 


6  External  Planner  Integration 

As  a  first  test  of  the  services  and  Cornerstone  system  workflow,  during  Phase  2,  we  surveyed 
candidate  planners  for  an  initial  integration  effort  and  settled  on  a  BAE  Systems  cyber-planner. 
This  planner  was  chosen  in  part  because  the  cyber-planner  was  still  under  active  development 
and  the  planner  team  shared  personnel  with  the  Cornerstone  team,  offering  maximum  flexibility 
and  shared  expertise.  The  cyber-planner  is  based  on  the  Generic  Modeling  Environment  (GME), 
a  “meta-modeling”  toolkit  originally  developed  by  Vanderbilt  Univ.  [GMEl,  GME2].  Using  a 
similar  approach  to  that  of  Cornerstone,  the  Arlington,  VA  team  first  used  GME  to  define  a 
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graphical  domain  model  for  the  cyber  domain  and  then  compiled  that  model  into  a  speeialized 
planning  tool.  The  tool  enables  graphical  authoring  of  cyber-plans  whose  elements  and 
relationships  conform  to  the  domain  model.  Unlike  Cornerstone,  the  eyber-planner  uses  an 
XML-based  schema  rather  than  OWL  and  RDF  to  represent  plans  (but  this  will  change  as  we 
progress  in  both  developments). 

Thus,  to  integrate  the  cyber-planner  with  Cornerstone,  we  performed  the  following  tasks: 

•  Developed  bi-directional  translators  from  the  eyber-planner  XML  format  to  Cornerstone’s 
format,  and  ineorporated  the  translators  within  the  Cornerstone  DTS. 

•  Added  a  eapability-model  of  the  cyber-planner  to  the  MMS. 

•  Incorporated  code  into  RMS  to  notify  the  eyber-planner  when  it  is  selected  from  the  list  of 
candidate  planners  to  provide  mission  options. 

We  have  yet  to  get  to  the  task  of  translating  support  requests  from  the  cyber-planner  because  our 
experiment  threads  have  not  yet  ealled  for  initiation  of  sueh  requests  from  the  cyber  domain. 
However,  we  have  successfully  developed  request  translators  for  the  MTR  and  SSR  requests  for 
the  air  and  space  domains  respectively  and  therefore  demonstrated  that  we  ean  do  it  for  any 
domain.  We  diseuss  the  results  of  end-to-end  experiments  with  the  cyber  planner  and  mission 
data  from  other  domains  in  the  next  section. 

7  Limited  Technology  Experiment 

At  the  end  of  Phase  2,  AFRL  organized  a  Limited  Technology  Experiment  (LTE)  in  order  to  test 
the  functionality  developed  to  date  and  establish  a  run-time  performance  baseline.  AFRL  has 
sueeessfully  applied  this  experimental  methodology  in  recent  years  to  SOA,  C2  and  Situational 
Awareness  researeh  to  establish  metries,  verify  milestones,  and  provide  formative  feedbaek  for 
ongoing  programs. 

Figure  8  illustrates  the  cross-domain  vignette  that  was  designed  for  the  Cornerstone  LTE.  The 
vignette  is  triggered  by  deteetion  of  indieators  of  a  direet  ascent  Anti- Satellite  (ASAT)  launeh  by 
a  notional  adversary.  This  leads  to  requests  for  missions  in  multiple  domains:  1)  a  cyber 
eapability  aetivation  against  the  adversary’s  C2  network  to  delay  the  ASAT  launeh  (so  that  we 
have  time  to  get  other  options  engaged),  2)  a  space  Overhead  Persistent  Infrared  (OPIR)  mission 
to  surveil  potential  targets,  3)  a  subsequent  air-attack  on  the  launch  facility,  and  4)  other  space 
ISR  missions  to  perform  Battle  Damage  Assessment  (BDA)  on  the  strike  targets,  and  to  monitor 
for  potentially  downed  aircraft  requiring  search-and-rescue  eontingency  missions.  The  vignette 
also  includes  a  ground-based  Speeial  Forces  insertion  mission,  but  was  not  exercised  in  the  first 
LTE  beeause  of  funding  scope  and  lower  priority  relative  to  the  air,  eyber,  and  space  domains; 
however,  we  are  planning  to  include  other  domain  eapabilities  in  future  LTEs  in  order  to 
demonstrate  that  we  ean  ineorporate  any  military  capability. 
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Space-Based  imagery/ 
SIGINT  assets  conduct 
ground  &  air  defense 
threat  evaluation 
before  SOF  air  insertion 


Offensive  Air  Assets 
Clear  SOF  Entry  &  Exit 
Air  Corridors. 
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optimized  for  accuracy 
over  AOR.  Downed 
pilot  Search  &  Rescue 
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Cyber  command 
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Space-Based 
assets  conduct 
post-attack  BDA 


Figure  8:  Cross-domain  LTE  vignette  calling  for  coordinated  air,  ground,  cyber,  and  space  missions, 
triggered  by  a  notional  direct  ascent  ASAT  threat. 

The  Cornerstone  team  coordinated  with  an  AFRL  integrated  C2  experimentation  team  who 
assisted  with  integration  into  the  ACS  SOA  environment  and  administered  the  execution  and 
data  collection  for  the  experiment  conducted  at  AFRL  Rome.  We  designed  four  LTE  threads  to 
exercise  different  aspects  of  the  software  described  earlier.  The  purpose,  metrics,  and  results  for 
each  thread  are  described  in  Table  1 . 


Table  1:  Summary  of  Cornerstone  LTE  threads,  metrics,  and  results 


Thread 

Purpose 

Metrics 

Results 

1.  Cross-Domain 
Mission  Processing 

Verify  successful  end-to-end 
processing  of  mission  requests 
for  air,  cyber,  space. 

Recall,  Accuracy:  %  of 
expected  data  reported, 

%  correct  output 

100%  recall  and  accuracy 
verified  by  air,  cyber,  space 
subject  matter  experts  for 
four  missions  (ten  trials) 

2.  Constraint 
Processing 

Verify  detection  of  violation 
of  no- strike  target  constraint 

%  correct  trials 

100%  expected  violations 
reported  (ten  trials) 

3.  Run-Time 
Performance 

Establish  baseline  system  and 
service-specific  average  run¬ 
time  and  memory  usage. 

Goal:  <  30  sec  end-to- 
end  runtime 

1 5  sec  for  initial  trials  but 
run-time  increased  over  the 
course  of  50  trials  due  to 
memory  leak  in  object 
cache  (fixed  after  LTE) 

4.  Dynamic  Model 
Extension 

Verify  successful  run-time 
extension  of  planner  capability 
model. 

%  correct  trials, 

#  unexpected  errors 

100%,  0  errors:  no  planners 
found  initially,  cyber¬ 
planner  found  after  model 
extension  (ten  trials) 

The  purpose  of  the  first  thread  was  to  exercise  the  end-to-end  system  workflow  for  mission 
request  processing,  ensuring  coverage  of  all  three  domains  (air,  cyber,  space).  The  deployment 
configuration  for  Cornerstone  included  the  Arlington  team’s  cyber-planner,  which  was  used  to 
generate  options  for  cyber-mission  requests.  The  cyber-planner  was  fully  integrated  with 
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Cornerstone  in  that  it  supported  automated  and  live  human-in-the-loop  interaction,  via  the 
Cornerstone  Planner  Interface  Service.  For  air  missions,  we  pre-loaded  the  Plan  Repository  with 
a  50-mission  dataset  adapted  from  the  previous  DARPA  JAGUAR  program.  For  space  missions, 
we  authored  the  OPIR  mission  artifacts  by  hand  using  an  XML  editor.  To  ensure  correctness 
and  accuracy  of  output  data,  we  assembled  a  Subject  Matter  Expert  (SME)  team  consisting  of 
analysts  with  experience  in  each  domain  to  analyze  pre-verified  mission  output  and  identify 
salient  XML  data  elements  to  use  as  a  ground  truth  basis  for  comparing  LTE  output.  During  the 
LTE,  the  SME  team  verified  that  Cornerstone  mission  output  contained  100%  of  expected  data 
elements,  and  no  inaccurate  or  unexpected  output  data  was  detected  from  manual  inspection  of 
all  output.  Likewise,  the  SME  team  verified  that  the  no-strike  constraint  violations  in  the  second 
LTE  thread  were  successfully  reported  by  RMS  for  all  trials. 

The  third  thread  was  administered  and  analyzed  primarily  by  the  AFRL  LTE  team.  This  thread 
used  the  same  mission  request  sequence  as  the  first  thread,  but  with  many  automatic  repetitions 
and  logging  of  the  timing  of  key  web  service  entry  and  exit  points.  This  was  done  to 
characterize  run-time  performance.  This  thread  duplicated  the  first  thread’s  end-to-end  run-time 
latency  of  15  sec,  well  under  our  goal  of  30  sec.  However,  over  the  span  of  fifty-repetition  trials, 
they  observed  that  run-time  linearly  increased  with  each  repetition  and  garbage  collection 
activity  tended  to  spike  more  frequently  on  the  later  repetitions.  They  also  found  that  RMS  and 
PM  Service  run-times  increased  linearly,  while  DTS  performance  remained  flat  throughout  all 
trials.  The  Cornerstone  team  traced  this  issue  to  a  memory  leak  in  the  PM  Service  object  cache, 
associated  with  the  ACS  JBOSS  methods.  The  leak  was  fixed  shortly  after  the  LTE  and  new 
performance  tests  verified  constant  run-time  even  after  thousands  of  trials  in  a  row. 

For  the  fourth  and  final  thread,  we  tested  whether  Cornerstone  could  process  a  dynamic 
extension  of  a  planner  capability  model  within  the  MMS.  Each  trial  featured  a  mission  request 
for  a  “Neutralize”  effect  that  was  processed  in  two  stages,  a  “before”  stage  and  an  “after”  stage: 

•  Before  the  dynamic  extension.  Neutralize  as  an  effect  was  not  included  in  any  of  the 
domain  planner  models  and  hence  requests  to  neutralize  a  target  should  yield  no  candidate 
planners. 

•  After  the  dynamic  extension,  RMS  should  suggest  the  cyber-planner  as  a  candidate  because 
its  capability  model  was  extended  to  include  the  Neutralize  effect  type. 

For  all  trials,  we  verified  that  the  correct  output  occurred  for  the  “before”  and  “after”  stages. 
However,  for  trials  in  which  the  ACS  JBOSS  environment  was  not  restarted  between  trials,  the 
“before”  behavior  incorrectly  matched  the  expected  “after”  behavior  for  the  second  and 
subsequent  trials  because  the  MMS  models  were  apparently  retaining  the  model  extension  from 
previous  trials.  Subsequent  ontology  refactoring  and  initialization  logic  improvements  after  the 
LTE  fixed  this  problem;  however,  this  points  to  a  curious  challenge  designing  and  deploying 
dynamically  changing  services;  a  subject  of  future  experimentation. 

We  also  conducted  some  exploratory  tests.  For  example,  the  cyber  SME  intentionally  entered 
invalid  dates  on  the  cyber  mission  option  and  verified  that  Cornerstone’s  semantic  reasoner 
detected  the  error  and  raised  an  exception.  After  correcting  the  dates  and  resending  the  option. 
Cornerstone  correctly  accepted  the  response  rather  than  dropping  the  request.  We  also  verified 
the  correct  locations  of  geospatial  air,  cyber,  and  space  mission  data  using  Google  Earth  to 
display  the  results  of  a  Keyhole  Markup  Language  (KML)  mission  data  translator.  Finally,  we 
successfully  ran  Thread  1  via  an  alternate  client  configuration,  in  which  the  air,  cyber,  and  space 
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clients  were  run  as  separate  processes.  This  verified  that  Cornerstone  services  could  support  a 
distributed  planning  environment,  which  is  the  most  likely  configuration  for  the  eventually 
deployed  system. 

8  Future  Research 

Having  achieved  a  successful  end-to-end  prototype  in  Phase  2,  future  plans  for  the  final  Phase  3 
experiment  with  Cornerstone  (Nov  201 1-Jan  2013)  include,  by  service: 

•  Integrate  Cornerstone  with  BAE  Systems’  DARPA  JAGUAR  automated  air  mission 
generator  and  CACI’s  AFRL-sponsored  Air-Space-Cyber  Universal  Client  as  the  space  tasking 
order  mission  management  and  visualization  tool.  Develop  additional  data  translators  within  the 
DTS. 

•  Extend  RMS  to  support  a  negotiation  protocol  in  which  Cornerstone  users  collaborate  with 
domain  planners  to  request  minor  adjustments  to  options  to  synchronize  missions  across 
domains. 

•  Extend  MMS  to  support  dynamic  registration  of  new  domain  planners.  Improve  the 
dynamic  extension  mechanism  to  support  on-the-fly  loading  of  new  ontology  segments  and 
translators  (i.e.,  to  support  a  new  external  domain  planner). 

•  In  the  PM  Service,  expose  finer- grained  CRUDE  access  to  additional  object  types  as 
appropriate. 

Over  the  course  of  Phase  3,  we  are  also  planning  to  develop  a  more  rigorous  test  harness  to  allow 
for  generation  of  a  large  number  of  test  artifacts  and  help  scale  Cornerstone  processing  to  handle 
hundreds  or  thousands  of  missions. 

BAE  Systems  has  also  begun  work  on  a  follow-on  project  entitled  Synchronized  Constraint- 
based  Optimization,  Repair,  and  Assembly  (SCORA),  which  will  add  automation  support  via 
optimal  search  algorithms.  Semantic  reasoning  is  being  used  for  selection  of  mission  options 
that  best  fulfill  a  set  of  desired  effects.  SCORA  will  also  use  plan  repair  techniques  to 
automatically  synchronize  multiple  cross-domain  missions,  and  it  will  add  a  capability  to 
assemble  and  publish  a  complete  integrated  battle  plan. 

9  Conclusion 

To  address  the  challenge  of  coordinating  complex  multi-domain  operations  among  air,  cyber, 
and  space  domains  and  their  multitude  of  security  domains,  AFRL  has  sponsored  the 
development  of  a  shared  representation  and  suite  of  coordination  and  synchronization  planning 
web  services  under  the  Cornerstone  project.  BAE  Systems  has  successfully  prototyped  and 
demonstrated  the  utility  of  this  collaborative  approach  via  services  for  request  management,  plan 
management,  and  dynamic  model  management.  We  have  successfully  integrated  Cornerstone 
with  an  existing  cyber-planner,  and  have  plans  to  incorporate  air  and  space  planners  in  Phase  3. 
AFRL’s  Phase  2  Limited  Technology  Experiment  verified  successful  end-to-end  mission  request 
processing  and  constraint  checking  and  established  baseline  metrics  for  run-time  performance. 
Most  importantly.  Cornerstone  demonstrated  the  ability  to  add  and  extend  capability  models  on- 
the-fly  to  support  new  mission  effects.  When  taken  to  its  fullest  potential.  Cornerstone’s 
approach  to  plan  and  model  management  promises  to  yield  significant  cost  and  time  savings  in 
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interoperations,  and  increase  C2  agility  in  deployed  environments.  As  we  make  progress,  we 
plan  on  including  all  Joint  domains  available  to  a  commander. 
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BAE  SYSTEMS 


Introduction  Metotcch 


•  Adversary  decision  cycles  are  fast,  complex  and  chaotic 

^C2  Agility 

•  Synchronized  Operations  Program:  AFRL  exploring  ways 
of  improving  coordination  and  synchronization  among  its 
mission  domains 

-  Air 

-  Space 

-  Cyber 

•  Experiments  revealed  need  for 

-  A  common  language  across  domains 

-  Persisting  collaboration  across  domains 

-  A  coherent  structure  to  guide  workflow  and  communication 
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R&D  Project 


Metotech 


•  Cornerstone 

-  Foundational  data  representation  and  suite  of  services 

•  Phase  1  (Mar-Nov  2010) 

-  AFRL,  BAE  Systems,  and  supporting  contractor  Metatech 

•  Conducted  knowledge  acquisition  workshops 

•  Collected  existing  schemas  and  Community  of  Interest  (COI)  docs 

•  Synthesized  salient  schemas  &  standards  into  a  shared  set  of  ontologies 

•  Phase  2  (Aug  2010-  Sep  2011) 

-  Prototyped  services 

-  Limited  Technology  Experiment 
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Cross-Domain  Knowledge 
Representation 
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Metotech 


•  Cornerstone  Core  "upper  ontology,"  core  model  layer 


•  Domain  Ontologies 

-  Air  Ontology,  Cyber  Ontology,  Space  Ontology 

-  Extend  general  concepts  into  each  domain 
•  Mission  ->  AirMission  ->  AirAttackMission 


•  Planner ->  CyberPlanner 

•  Request  ->  SpaceRequest 


-  Define  properties  and  classes  specific  to  a  domain 


•  Air:  Sorties  and  Route  Points,  Cyber:  ComputerNetworkNode 
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Cornerstone  Core  Ontology  Metotcch 


•  Subset  of  the  Core  Ontology  which  illustrates  how 
general  classes  have  sub-classes  that  open  up  the 
domains 
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Cornerstone  Ontology  Derivation  Mctotech 
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Metotech 
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Afloat  Core  Services 
Common  Service  Stack 
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Plan  Management  Service  Metotcch 


•  Provides  actively  changing  battle  plans  across  mission  and 
security  domains 

-  Create,  Read,  Update,  Delete,  Find  (CRUDF) 

•  Managed  Objects 

-  Request  -  Plan 

-  Task  -  Query 

-  Mission  -  Ontology 

•  Repository 

-  Underlying  storage  is  OWL  RDF  triples  stored  in  a  SQL  database 

•  PostgreSQL,  MySQL,  etc. 

-  Multiple  Stored  representations 

•  OWL  representation 

•  External  representations  are  always  available 

•  Pub/Sub  notifications  for  Managed  Object  lifecycle  events 
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Model  Management  Service 


Metotech 


•  Similar  to  Plan  Management  Service,  but  stores  "World 
State": 

-  Current  Domain  Ontologies  (Air,  Cyber,  Space) 

-  Planner  instances  and  capabilities 

•  Air  Operations  Centers  (regional  and  global) 

•  Joint  Space  Operations  Center 

•  Cyber  Operations  Center 

-  Targets 

-  Geography 

•  Publishes  change  notifications  or  reports  on-demand 
updates/differences 

•  Generic  ModelDataSource  interface 


Distro  A 


9 


BAE  SYSTEMS 


Request  Management  Service  Mciotech 


•  Matches  request  to  Planner  using  Capability  models  for  Planners 

•  Track  request  Responses  and  Options 


Main  Plan 


Support  Requests 


- > 


Request  (time,  constraints,  state) 


Planner 
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Support  requested  from  this  planner 


Task 
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Response 
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Support  requested  for  this  Task 
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Response  from  planner 


Plan 
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Task  —  Mission 


Request 
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Planner 
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Planner  Chooser  Capabilities 


Metotech 


•  Planner  Chooser  matches  Requests  to  Planners  using  Capabilities  and 
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Planner  Interface  Service  Metotcch 


•  The  Planner  Interface  Service  acts  as  a  central  interface 
point  for  non-Cornerstone-aware  planners 

-  Maps  external  documents  to  Cornerstone  Managed  Objects  using 
the  Data  Translation  Service 

-  Maps  external  workflow  to  Cornerstone's  using  the  Request 
Management  Service 

•  External  Planner  Integration 

-  Translation 

•  JAGUAR  (Air) 

•  GME  (Cyber) 

•  ASC2EM  (Space) 

•  Others  to  follow 

-  Web/SOA  connectivity 

•  Future 
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Data  Translation  Service 


BAE  SYSTEMS 


Metotech 


Take  in  documents  in  currently  used  representations  such  as  the  Air 
Operations  Community  of  Interest's  MTR  (Mission  Task  Request)  and  CMD 
(Common  Mission  Definition)  format,  and  produce  OWL  models  that  are  in 
the  common  Cornerstone  ManagedObject  format 


External 

translate 

Data 

create 

XML  Doc 

A 

Planner 

Translation 

A 

Service 

retrieve 

Data  Translation  understands: 

-  Air  formats:  MTR,  CMD, 

JAGUAR  Objective  and  Activity 

-  Space  formats:  Joint  Space  Tasking  Order  (JSTO) 

Space  Support  Request  (SSR) 

-  Cyber  formats:  Generic  Modeling  Environment  (GME) 

-  Produces  Google  Earth:  KML 
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Limited  Technology  Experiment  Mctotech 


Blue  Space 
Command  Center 
requests  cyber  attack 
on  launch  site  to 
Delay  ASAT  Launch 


Space-Based 
imagery  INTEL 
predicts  that  Red  is 
initiating  launch 
preparations  for 
direct  ascent  ASAT 


SOFTeam  is 
tasked  to  insert 
and  Permanently 
Neutralize  Site 


Strategic 

Planner 


1 


Space  Ops 
Planner 


[f 


Air  Ops  Planner 


il 


Cyber  Ops 
Planner 


Ground  Ops 
Planner 


Possible  space 
targets  are  tasked 
to  temporarily 
maneuver  out  of 
threat  zone  (Space 
Wings  Mission). 


Space-Based  imagery  / 
SIGINT  assets  conduct 
ground  &  air  defense 
threat  evaluation 
before  SOF  air  insertion 


Cyber  command 
conducts  CNA  to 
disable  enemy  systems 


Offensive  Air  Assets 
Clear  SOF  Entry  &  Exit 
Air  Corridors. 


GPS  constellation  is 
optimized  for  accuracy 
over  AOR.  Downed 
pilot  Search  &  Rescue 
Satellite  support  is 
also  optimized 


SOF  Team 
storms  the  site 


Space-Based 
assets  conduct 
post-attack  BDA 
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Limited  Technology  Experiment 


Metotech 


•  Air,  Cyber  and  Space  planners  coordinate  response  to  the  threat  of  an  ASAT  launch 
via  Cornerstone  services 

•  Air  Request  with  "no-strike"  target  (a  hospital)  rejected  through  constraint  checker 

•  Stress  test  of  cross-domain  thread  run  50  times  (later  increased  to  1000) 

•  New  Cyber  capability  added  during  runtime  via  ontology  update 


Thread 

Purpose 

Metrics 

Results 

1.  Cross-Domain 
Mission  Processing 

Verify  successful  end-to-end 
processing  of  mission  requests 
for  air,  cyber,  space. 

Recall,  Accuracy:  %  of 
expected  data  reported, 

%  correct  output 

100%  recall  and  accuracy 
verified  by  air,  cyber,  space 
subject  matter  experts  for 
four  missions  (ten  trials) 

2.  Constraint 
Processing 

Verify  detection  of  violation  of 
no-strike  target  constraint 

%  correct  trials 

100%  expected  violations 
reported  (ten  trials) 

3.  Run-Time 
Performance 

Establish  baseline  system  and 
service-specific  average  run¬ 
time  and  memory  usage. 

Goal:  <  30  sec  end-to-end 
runtime 

15  sec  for  initial  trials  but 
run-time  increased  over  the 
course  of  50  trials  due  to 
memory  leak  in  object  cache 
(fixed  after  LTE) 

4.  Dynamic  Model 
Extension 

Verify  successful  run-time 
extension  of  planner  capability 
model. 

%  correct  trials, 

#  unexpected  errors 

100%,  0  errors:  no  planners 
found  initially,  cyber-planner 
found  after  model  extension 
(ten  trials) 
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Future  Research  Mctotech 


•  Request  Negotiation 

•  Fully  integrate  Cornerstone  with  existing  Planners 

•  Extend  the  Model  Management  Service 

•  Test  Harness 

-  Allow  for  generation  of  large  numbers  of  test  artifacts 

-  Support  producing  realistic  load  levels  of  requests  and  missions: 
hundreds  to  thousands 

•  SCORA  --BAE  Systems  has  begun  work  on  a  related  project 
entitled  Synchronized  Constraint-based  Optimization,  Repair, 
and  Assembly  (SCORA) 

-  Planning  automation  support  via  optimal  search  algorithms 

-  Find  ''best''  combination  of  missions  options  to  fulfill  a  set  of  desired 
effects. 

-  Research  plan  repair  techniques  to  synchronize  multiple  cross-domain 
missions 

-  Assemble  and  publish  a  complete  integrated  battle  plan. 
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Conclusion  Metotcch 


•  Experiments 

•  Unified  Plan  Representation 

•  Set  of  Collaboration  Services 


This  research  was  sponsored  by  Air  Force  Research  Laboratory  Information  Directorate,  under 
Contract  #  FA  8750-10-C-0043 
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